CD Actual 2

home *** CD-ROM | disk | FTP | other *** search

/ CD Actual 2 / CD ACTUAL VOL 2.iso / docs / elf-howt < prev next >

Wrap

Text File | 1995-09-10 | 33.1 KB | 859 lines

The Linux ELF HOWTO Daniel Barlow <daniel.barlow@sjc.ox.ac.uk> v1.03, August 1995 This document describes how to migrate your Linux system to compile and run programs in the ELF binary format. It falls into three con- ceptual parts: (1) What ELF is, and why/whether you should upgrade, (2) How to upgrade to ELF-capability, and (3) what you can do then. 1. What is ELF? An introduction ELF (Executable and Linking Format) is a binary format originally developed by USL (UNIX System Laboratories) and currently used in Solaris and System V Release 4. Because of its increased flexibility over the older a.out format that Linux currently uses, the GCC and C library developers decided last year to move to using ELF as the Linux standard binary format also. This `increased flexibility' manifests as essentially two benefits to the average applications progammer: o It is much simpler to make shared libraries with ELF. Typically, just compile all the object files with -fPIC, then link with a command like gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o Now that may look complex, but it's far simpler than the method for a.out shared libraries, which involves reserving space for all the data you think that the library is likely to require in future, and registering that address space with a third party (it's described in a document over 20 pages long --- look at <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.16.tar.gz> for details). o It makes dynamic loading (ie programs which can load modules at runtime) much simpler. This is used by Perl 5, Python, and the ongoing port of Java to Linux, among other things. Other suggestions for dynamic loading have included super-fast MUDs, where extra code could be compiled and linked into the running executable without having to stop and restart the program. Against this it must be weighed that ELF is reputed to be possibly a bit slower. The figures that get bandied around are between 2% and 5%, though as far as I know nobody has done any proper testing. If you do know of any comparative tests, please let me know too. The slowdown comes from the fact the ELF library code must be position independent (this is what the -fPIC above is for) and so a register must be devoted to holding offsets. That's one less for holding variables in, and the 80x86 has a paucity of general-purpose registers anyway. 1.1. What ELF isn't There are a number of common misconceptions about what ELF will do for your system: It's not a way to run SVR4 or Solaris programs Although it's the same binary `container' as SVR4 systems use, that doesn't mean that SVR4 programs suddenly become runnable on Linux. It's analogous to a disk format --- you can keep Linux programs on MSDOS or Minix-format disks, and vice versa, but that doesn't mean that these systems become able to run each others' programs. It is theoretically possible to run applications for other x86 Unices under Linux, but following the instructions in this HOWTO will not have that effect. Start by looking at the iBCS kernel module (somewhere on tsx-11.mit.edu) and see if it fits your needs. It's not intrinsically smaller or faster You may well end up with smaller binaries anyway, though, as you can more easily create shared libraries of common code between many programs. In general, if you use the same compiler options and your binaries come out smaller than they did with a.out, it's more likely to be fluke or a different compiler version. As for `faster', I'd be surprised. Speed increases could turn up if your binaries are smaller, due to less swapping or larger functional areas fitting in cache. It doesn't require that you replace every binary on your system At the end of this procedure you have a system capable of compiling and running both ELF and a.out programs. New programs will by default be compiled in ELF, though this can be overridden with a command-line switch. There is admittedly a memory penalty for running a mixed ELF/a.out system --- if you have both breeds of program running at once you also have two copies of the C library in core, and so on. I've had reports that the speed difference from this is undetectable in normal use on a 6Mb system though (I certainly haven't noticed much in 8Mb), so it's hardly pressing. You lose far more memory every day by running bloated programs like Emacs and static Mosaic/Netscape binaries :-) It's nothing to do with Tolkien, Pratchett, Keebler, or general mythology" Or at least, not in this context. 'Nuff said. 1.2. Why you should(n't) convert to ELF There are essentially two reasons to upgrade your system to compile and run ELF programs: the first is the increased flexibility in programming referred to above, and the second is that, due to the first, everyone else will be too. Future releases of the C library and GCC will only be compiled for ELF, and other developers are expected to move ELFwards too. Pleasingly for the purposes of symmetry, there are also two reasons not to convert at this time. The first is that things are still changing, some packages (including the `stable' 1.2 kernel series) require patches to be made before they will compile in ELF, and there may be residual bugs; one could make a strong case for waiting until Linus himself has converted, for example. The second is that although the installation described here is a fairly small job in itself (it can be completed in well under an hour, excepting the time taken to download the new software), an error at almost any stage of it will probably leave you with an unbootable system. If you are not comfortable with upgrading shared libraries and the commands ldconfig and ldd mean nothing to you, you may want to obtain or wait for a new Linux distribution in ELF, and backup, reinstall and selectively restore your system using it. Then again (and especially if the system is not mission-critical) you may want to go through it anyway and look on it as a learning experience. Still with us? 2. Installation 2.1. Background The aim of this conversion is to leave you with a system which can build and run both a.out and ELF programs, with each type of program being able to find its appropriate breed of shared libraries. This obviously requires a bit more intelligence in the library search strategy than the simple `look in /lib, /usr/lib and anywhere else that the program was compiled to search' strategy that some other systems can get away with. The beastie responsible for searching out libraries in linux is /lib/ld.so. The compiler and linker do not encode absolute library pathnames into the programs they output; instead they put the library name and the absolute path to ld.so in, and leave ld.so to match the library name to the appropriate place at runtime. This has one very important effect --- it means that the libraries that a program uses can be moved to other directories without recompiling the program, provided that ld.so is told to search the new directory. This is essential for the directory swapping operation that follows. The corollary of the above, of course, is that any attempt to delete or move ld.so will cause every dynamically linked program on the system to stop working. This is generally regarded as a Bad Thing. For ELF binaries, an alternate dynamic loader is provided. This is /lib/ld-linux.so.1, and does exactly the same thing as ld.so, but for ELF programs. ld-linux.so.1 uses the same support files and programs (ldd, ldconfig, and /etc/ld.so.conf) as the a.out loader ld.so does. The basic plan, then, is that ELF development things (compilers, include files and libraries) go into /usr/{bin,lib,include} where your a.out ones currently are, and the a.out things will be moved into /usr/i486-linuxaout/{bin, lib, include}. /etc/ld.so.conf lists all the places on the system where libraries are expected to be found, and ldconfig is intelligent enough to distinguish between ELF and a.out variants. There are a couple of exceptions to the library placement, though; see the Caveats section below. 2.2. Before you start --- Notes and Caveats o You will need to be running a post-1.1.52 kernel with ELF binary format support. Note that kernel versions 1.3.0 to 1.3.2 inclusive had an ELF-related bug. If you're running the development 1.3 kernel series, make sure you stay current! 1.3.3 is fine, as is 1.2.10 (the latest stable kernel at time of writing). o You are recommended to prepare or acquire a linux boot/root disk, such as a Slackware rescue disk. You probably won't need it, but if you do and you don't have one, you'll kick yourself. In a similar `prevention is better than cure' vein, statically linked copies of mv, ln, and maybe other file manipulation commands (though in fact I think you can do everything else you actually need to with shell builtins) may help you out of any awkward situations you could end up in. o Extra care is needed if you have /usr or /usr/lib on a separate partition from /. You will need to check the libraries that your programs in /bin and /sbin use, and put those libraries somewhere on the root partition, say in /lib-aout. I'll come back to this at the appropriate spot. o If you have been following the ELF development, you may have ELF libraries in /lib/elf (usually libc.so.4 and co). Applications that you built using these should be rebuilt, then the directory removed. There is no need for a /lib/elf directory! It was used for a time during ELF development, but how it ended up as a standard directory in Slackware installs, who knows? o Some old programs don't use ld.so, so any libraries that they depend on cannot be moved. There may or may not be a problem here. Use ldd to determine which these libraries are. If the program depends only on libc.so.4 and/or libm.so.4, there is no problem, as these libraries continue to reside in /lib. If it depends on X in any way, shape, or form, you're also safe: to be old enough not to use ld.so it would have to have been compiled with a pretty old version of the X libraries, and both the major version number and directory placement of the X libraries has changed since then. If you do have a clash between an a.out library that cannot be moved and an ELF library with the same major version that wants to install over the top of it, you'll have to put the ELF library somewhere else and add the other directory to /etc/ld.so.conf. If your system is old enough that you still have shared libraries with dates in the filenames then you're obviously a Linux God(tm) and should be advising me on the appropriate course of action at this point :-) Answers to the address in the title of this HOWTO. o Most Linux installations these days have converged on the `FSSTND' standard file system, but doubtless there are still installed systems that haven't. If you see references to /sbin/something and you don't have a /sbin directory, you'll probably find the program referred to in /bin or /etc/. 2.3. You will need ... The following packages are available from <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> and <ftp://sunsite.unc.edu/pub/Linux/GCC/>. Both sites are widely mirrored; please take the time to look up your nearest mirror site and use that instead of the master sites where possible. It's faster for both you and everyone else. These packages (either the listed version or a later one) are required. Also download and read through the release notes for each of them: these are the files named release.packagename. This applies especially if you get newer versions than are listed here, as procedures may have changed. o ld.so-1.7.3.tar.gz --- the new dynamic linker o libc-5.0.9.bin.tar.gz --- the ELF shared images for the C library and its friends (m (maths), termcap, gdbm, and so on), plus the corresponding static libraries and the include files needed to compile programs with them. o gcc-2.7.0.bin.tar.gz --- the ELF C compiler. Also includes an a.out C compiler which understands the new directory layout. o binutils-2.5.2l.17.bin.tar.gz --- the GNU binary utilities patched for Linux. These are programs such as gas, ld, strings and so on, most of which are required to make the C compiler go. Note that you can also use binutils-2.5.2l.20.bin.tar.gz, if it's arrived in your part of the world. 2.4. Rearranging your filesystem Sooo... Note that in all that follows, when I say `remove' I naturally mean `backup then remove' :-). Also, these instructions directly apply only to people who haven't yet messed with ELF --- those who have are expected to have the necessary nous to adapt as appropriate. Let's go! 1. If you have separate / and /usr partitions, some caution is required here. You must check each program that is run at startup before /usr is mounted, or run in other situations where /usr is unavailable, and put all the libraries required by it in /lib-aout. This is actually less tedious than it sounds. Simply run $ ldd /sbin/* /bin/* /etc/* >/tmp/list.txt and then look through /tmp/list.txt , ignoring all the errors from non-executable files, and noting which libraries appear. These are the libraries which you will need on the root partition. Keep this list. 2. Make the new directories that you will move a.out things to ______________________________________________________________________ mkdir -p /usr/i486-linuxaout/bin mkdir -p /usr/i486-linuxaout/include mkdir -p /usr/i486-linuxaout/lib mkdir /lib-aout ______________________________________________________________________ 3. Untar the dynamic linker package ld.so-1.7.3 in the directory you usually put source code, then read through the ld.so-1.7.3/instldso.sh script just unpacked. If you have a really standard system, run it by doing sh instldso.sh, but if you have anything at all unusual then do the install by hand instead. `Anything at all unusual' includes o using zsh as a shell (some versions of zsh define $VERSION, which seems to confuse instldso.sh) o having symlinks from /lib/elf to /lib (which you shouldn't need, but you may have valid reasons for if you have been following the ELF development) Edit /etc/ld.so.conf to add the new directory /usr/i486-linuxaout/lib (and /lib-aout if you're going to need one). Then rerun /sbin/ldconfig -v to check that it is picking up the new directories. 4. Move all your a.out libraries in /usr/*/lib to /usr/i486-linuxaout/lib. If /usr is not on the root partition, refer now to the list you made of libraries that are needed in single-user mode, and move them from /lib to /lib-aout. After doing that, or if you didn't need to do that, move all remaining libraries in /lib to /usr/i486-linuxaout/lib. Don't move, delete or do anything with /lib/ld.so! For people with only the one partition, the following series of commands are pretty well what you need to do. ______________________________________________________________________ cd /lib mv *.o *.a *.sa /usr/i486-linuxaout/lib mv libfoo.so* libbar.so* libmumble.so* /usr/i486-linuxaout/lib cd /usr/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib cd /usr/X11R6/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib cd /usr/local/lib mv *.o *.a *.so* *.sa /usr/i486-linuxaout/lib ______________________________________________________________________ If you actually typed in the third line of that without reading it first, you'll observe that it didn't do anything. What you should be attempting to do there is move all files matching *.so* except for libc.so*, libm.so* and libdl.so* to /usr/i486-linuxaout/lib. I can't advise more specifically than that as I don't know what libraries you have in /lib Do not pass this stage until you have removed all libraries and object (*.o) files from each of the above directories, except for libc.so*, libm.so* and libdl.so* in /lib, which you need to keep so that aged programs continue to work, and ld.so in /lib, which you still need for anything to work. Now run ldconfig again. 5. Remove the directory /usr/lib/ldscripts if it's there. 6. Remove any copies of ld and as (except for ld86 and as86) that you can find in /usr/bin. 7. Some versions of GNU tar appear to have problems dealing with symbolically linked files. Before installing the libc images you might want to go through /usr/include and remove some parts. This is icky. Many packages (such as ncurses) are installed into /usr/include by distribution maintainers and are not supplied with the C library. Backup the /usr/include tree, use tar tzf to see what's in the file before untarring it, and delete the directories that it actually fills. Then untar the libc-5.0.9.bin.tar.gz package from root. 8. Install the binutils package. tar -xvzf binutils-2.6.2.l17.bin.tar.gz -C / is one perfectly good way to do this. 9. You have now installed everything you need to run ELF executables. Medical experts recommend that VDU workers take regular breaks away from the screen; this would be an opportune moment. Don't forget what you were doing, though; depending on the version of gcc you were previously using, you may have left yourself unable to compile programs in a.out until you unpack the new gcc. 10. Backup and remove everything in /usr/lib/gcc-lib/{i486-linux, i486-linuxelf, i486-linuxaout}/ Then install the gcc package, again by untarring from root. 11. Some programs (notably various X programs) use /lib/cpp, which under Linux is generally a link to /usr/lib/gcc- lib/i486-linux/version/cpp. As the preceding step wiped out whatever version of cpp it was pointing to, you'll need to recreate the link: $ cd /lib $ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp . Done! Simple tests that you can try are ______________________________________________________________________ $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs gcc version 2.7.0 $ gcc -v -b i486-linuxaout Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs gcc version 2.7.0 $ ld -V ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11) Supported emulations: elf_i386 i386linux i386coff ______________________________________________________________________ followed of course by the traditional ``Hello, world'' program. Try it with gcc and with gcc -b i486-linuxaout to check that both the a.out and ELF compilers are set up corectly. 2.5. Common errors I'm soliciting reports of people's problems for this section. Your anonymity will be preserved if you so request :-) no such file or directory: /usr/bin/gcc that the ELF dynamic loader /lib/ld-linux.so.1 is not installed, or is unreadable for some reason. You should have installed it at around step 3 of the previous section. not a ZMAGIC file, skipping from ldconfig. You have an old version of the ld.so package, so get a recent one. Again, see step 3 of the previous section. bad address on attempting to run anything ELF. You're using kernel 1.3.x, where x<3. Upgrade to 1.3.3 or downgrade to 1.2.something _setutent: Can't open utmp file You didn't read the libc release notes. In accordance with version 1.2 of the FSSTND, utmp and wtmp have moved again, and should now be located in /var/run and /var/log respectively. Recommended practice is to add symlinks from their old locations so that your older programs will also find them. Don't forget to check your startup scripts (/etc/bcheckrc, for example) to make sure you're not deleting things you shouldn't at startup. gcc: installation problem, cannot exec something: No such file or directory when attempting to do a.out compilations (something is usually one of cpp or cc1). Either it's right, or alternatively you typed $ gcc -b -i486-linuxaout when you should have typed $ gcc -b i486-linuxaout Note that the `i486' does not start with a dash. 3. Building programs in ELF 3.1. Ordinary programs To build a program in ELF, use gcc as always. To build in a.out, use gcc -b i486-linuxaout . ______________________________________________________________________ $ cat >hello.c main() { printf("hello, world\n"); } ^D $ gcc -o hello hello.c $ file hello hello: ELF 32-bit LSB executable i386 (386 and up) Version 1 $ ./hello hello, world ______________________________________________________________________ This is perhaps an appropriate time to answer the question ``if a.out compilers default to producing a program called a.out, what name does an ELF compiler give its output?''. Still a.out, is the answer. Boring boring boring ... :-) 3.2. Building libraries To build libfoo.so as a shared library, the basic steps look like this: ______________________________________________________________________ $ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o $ ln -s libfoo.so.1.0 libfoo.so.1 $ ln -s libfoo.so.1 libfoo.so $ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ______________________________________________________________________ This will generate a shared library called libfoo.so.1.0, and the appropriate links for ld (libfoo.so) and the dynamic linker (libfoo.so.1) to find it. To test, we add the current directory to LD_LIBRARY_PATH. When you're happpy that the library works, you'll have to move it to, say, /usr/local/lib, and recreate the appropriate links. Note that the libfoo.so link should point to libfoo.so.1, so it doesn't need updating on every minor version number change. The link from libfoo.so.1 to libfoo.so.1.0 is kept up to date by ldconfig, which on most systems is run as part of the boot process. ______________________________________________________________________ $ su # cp libfoo.so.1.0 /usr/local/lib # /sbin/ldconfig # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so ) ______________________________________________________________________ 3.3. Programs with dynamic loading These are covered extensively in H J Lu's ELF programming document, and the dlopen(3) manual page, which can be found in the ld.so package. Here's a nice simple example though: link it with -ldl ______________________________________________________________________ #include <dlfcn.h> #include <stdio.h> main() { void *libc; void (*printf_call)(); if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY)) { printf_call=dlsym(libc,"printf"); (*printf_call)("hello, world\n"); } } ______________________________________________________________________ 3.4. Debugging Your existing copy of gdb will most likely work unchanged with ELF programs. The new version in the GCC directory on tsx-11 is reported to be better at debugging programs that use dynamic loading and to understand ELF core dumps. At the time of writing, a patch to the kernel is necessary before ELF programs will generate core dumps anyway, so it's perhaps a little academic. 4. Patches and binaries At this point in the proceedings, you can, if you like, stop. You have installed everything necessary to compile and run ELF programs. You may wish to rebuild some programs in ELF, either for purposes of `neatness' or to minimise memory usage. For most end-user applications, this is pretty simple; some packages however do assume too much about the systems they run on, and may fail due to one or more of: o Different underscore conventions in the assembler: in an a.out executable, external labels get _ prefixed to them; in an ELF executable, they don't. This makes no difference until you start integrating hand-written assembler: all the labels of the form _foo must be translated to foo, or (if you want to be portable about it) to EXTERNAL(foo) where EXTERNAL is some macro which returns either its argument (if __ELF__ is defined) or _ concatenated with its argument if not. o Differences in libc 5 from libc 4. The interface to the locale support has changed, for one. o The application or build process depends on knowledge of the binary format used --- emacs, for example, dumps its memory image to disk in executable format, so obviously needs to know what format your executables are in. o The application consists of or includes shared libraries (X11 is the obvious example). These will obviously need changes to accomodate the different method of shared library creation in ELF. Anyway, here are two lists: the first is of programs that needed changing for ELF where the changes have been made (ie that you will need new versions of to compile as ELF), and the second is of programs that still need third-party patches of some kind. 4.1. Upgrade: o Dosemu. Modulo the three or four cuurrent dosemu development trees (don't ask, just join the linux-msdos mailing list), dosemu runs with ELF. You'll need to monkey with the Makefile. Current versions of dosemu are available from <ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/> o Emacs. Emacs has a rather odd build procedure that involves running a minimal version of itself, loading in all the useful bits as lisp, then dumping its memory image back to disk as an executable file. (FSF) Emacs 19.29 and XEmacs 19.12 (formerly Lucid Emacs) can both detect whether you are compiling as ELF and Do The Right Thing automatically. o MAKEDEV. In some incarnations, this utility removes existing entries for devices before recreating them. This is Bad News if it happens to touch /dev/zero, as said device is necessary to the operation of all ELF programs. See the util-linux package(q.v.) for a fixed version. o perl 5.001. Perl 5.001 plus the ``official unofficial'' patches a- e will compile unchanged on an ELF system, complete with dynamic loading. The patches are available from ftp.metronet.com or ftp.wpi.edu o The cal program in util-linux 2.2 doesn't work. Upgrade to version 2.4 <ftp://tsx-11.mit.edu/pub/linux/packages/utils> or later. o XFree86. XFree86 3.1.2 comes in both a.out and ELF formats. ftp to ftp.xfree86.org, read the `too many users' message that you are almost guaranteed to get, and pick the closest mirror site network- wise to you. I confess to not having actually tried this yet. At time of writing, it's only been out for one day ;-) 4.2. Patch o e2fsutils. The Utilities for the Second Extended File System need a patch from <ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz> to compile correctly as a shared library. Remy Card says ``This is the ELF patch which will probably be included in the next release of e2fsck and co'' o file. This works anyway, but can be improved: <http://sable.ox.ac.uk/~jo95004/patches/file.diff> adds support for identifying stripped and mixed-endian ELF binaries. o The Kernel. As from at least 1.3.8, the development 1.3 series have a make config option to build using ELF tools. If you are using the 1.2 series, you have two options: 1. Patch the Makefile slightly to use the a.out compiler. Just change the CC and LD definitions to be ___________________________________________________________________ LD =ld -m i386linux CC =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include ___________________________________________________________________ Alternatively, 2. Apply H J Lu's patch which allows compiling the kernel in ELF (and also adds the ability to do ELF core dumps). Let me reiterate that neither of these is necessary for the 1.3 series. o ps (procps-0.97) The psupdate program needs a patch to work if you have compiled the kernel as ELF. It's available in <linux.nrao.edu:/pub/people/juphoff/procps>, both as a patch to vanilla 0.97 and as an entire tar-file. A new version of procps is expected to be released soon with this patch in place, so if you can find procps 0.98 by the time you read this, this patch will probably be obsolete. o SVGATextMode requires a single simple adjustment. Cut out the diff below and apply it, or else make the patch by hand. ______________________________________________________________________ --- SVGATextMode-0.7.orig/XFREE/os-support/assyntax.h Sun Feb 26 18:58:15 1995 +++ SVGATextMode-0.7/XFREE/os-support/assyntax.h Thu Mar 30 07:52:03 1995 @@ -211,7 +211,7 @@ #endif /* ACK_ASSEMBLER */ -#if (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) +#if (defined (__ELF__) || defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) #define GLNAME(a) a #else #define GLNAME(a) CONCAT(_,a) ______________________________________________________________________ 5. Further information o The linux-gcc mailing list is really the best place to see what's happening, usually without even posting to it. Remember, it's not Usenet, so keep the questions down unless you're actually developing. For instructions on joining the mailing list, mail a message containing the word help to majordomo@vger.rutgers.edu o There's a certain amount of information about what the linux-gcc list is doing at my ELF web page <http://sable.ox.ac.uk/~jo95004/elf.html>, when I remember to update it. Archives of the list itself are at <http://homer.ncm.com/>. o See also Bobby Shmit's ELF upgrade experience <http://www.intac.com/~cully/elf.html> web page. o The GCC-FAQ <ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC- FAQ.html> contains much general development information and some more technical ELF details. o There's also documentation for the file format on tsx-11 <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz>. This is probably of most use to people who want to understand, debug or rewrite programs that deal directly with binary objects. o H J Lu's document ELF: From The Programmer's Perspective <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz> contains much useful and more detailed information on programming with ELF. If you aren't LaTeX-capable, it is also available as PostScript. o There is a manual page for dlopen(3) supplied with the ld.so package. 6. Legalese All trademarks used in this document are acknowledged as being owned by their respective owners. (Spot the teeth-gritting irony there...) The right of Daniel Barlow to be identified as the author of this work has been asserted in accordance with sections 77 and 78 of the Copyright Designs and Patents Act 1988. (Proof by assertion This document is copyright (C) 1995 Daniel Barlow <daniel.barlow@sjc.ox.ac.uk> It may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator, at gregh@sunsite.unc.edu via email, or at +1 404 853 9989.